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SECTION  1 


INTRODUCTION 


LIMITATIONS  OF  EXISTING  VALIDATION  TECHNIQUES 

Considerable  effort  has  been  directed  over  the  past  several 
years  at  developing  formal  techniques  for  security  validation. 
Although  substantial  gains  have  been  made,  there  remain  a number  of 
problems: 

a.  Most  of  the  work  so  far  has  concentrated  on  validating 
software,  and  very  few  of  the  results  are  applicable  to 
hardware . 

b.  The  existing  security  tests  are  stronger  than  is  necessrry. 
It  is  therefore  possible  for  a secure  system  to  be  rejected 
as  insecure. 

c.  Present  techniques  have  difficulty  in  handling  the  subtle 
compromises  due  to  'modulation'  and  'timing'  channels. 

d.  None  of  the  techniques  so  far  developed  has  been  completely 
automated.  Typically,  a large  part  of  the  validation 
effort  requires  human  intervention. 

e.  Most  existing  validation  approaches  are  applicable  at  only 
a single  level  of  detail  - for  instance,  the  operating- 
system  level  or  the  assembly-language  level.  No  approach 
is  applicable  across  all  levels  of  detail. 

f.  The  issues  of  'data  integrity'  and  'denial  of  service'  have 
not  been  addressed. 

It  was  with  these  limitations  in  mind  that  MITRE  began  looking  for  a 
more  suitable  approach  to  formal  security  validation. 


A NEW  APPROACH 

The  initial  effort  at  MITRE  in  overcoming  these  limitations 
produced  some  promising  results.  It  was  discovered  that  the 
compromise  of  information  is  intimately  related  to  the  concept  of  a 
'prime  constraint'.  With  prime  constraints  it  was  now  possible  to 
state  a necessary  and  sufficient  condition  for  the  existence  of 
compromise.  A compromise  would  therefore  be  detected  if,  and  only 
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if,  one,  in  fact,  existed.  This  emerging  technique  also  appeared  to 
be  general  enough  to  handle  both  hardware  and  software,  and  flexible 
enough  to  be  applied  at  any  level  of  detail.  In  short,  it  looked  as 
if  prime  constraints  would  provide  the  key  to  overcoming  many  of  the 
limitations  of  existing  techniques. 

There  was,  however,  one  major  obstacle:  There  was  no  effective 
procedure  known  to  test  for  the  existence  of  a prime  constraint  of  a 
specified  type.  Without  this  ability  it  was  not  possible  to  test 
for  compromise.  Most  of  the  difficulty  stemmed  from  the  fact  that  a 
finite  system  could  have  an  infinite  number  of  prime  constraints, 
and  so  it  was  not  possible  to  exhaustively  check  each  prime 
constraint  for  potential  compromises . 

Clearly,  what  was  needed  was  a finite  representation  for  a 
possibly- infinite  set  of  prime  constraints  and  an  algorithm  for 
generating  that  representation.  It  is  just  such  a representation 
and  algorithm  that  we  describe  in  this  report.  The  'prime- 
constraint  graph'  of  a system  is  a finite  graph  in  which  every  prime 
constraint  is  represented  by  a path.  With  this  graph  it  is  a 
straightforward  matter  to  determine  what  compromises,  if  any,  are 
possible . 


OUTLINE  OF  THE  REPORT 

Section  2 reviews  the  five  basic  concepts  underlying  our  model: 
'conditions',  'variables',  'states',  'transitions',  and 
'simulations'.  The  notions  of  'constraint'  and  'prime  constraint' 
are  also  presented,  along  with  the  'deduction  theorem'  which 
establishes  the  relationship  between  prime  constraints  and  the 
compromise  of  information. 

The  'prime-constraint  graph'  of  a system  is  discussed  in 
Section  3>  and  the  user  interface  of  an  automated  tool  for 
generating  the  graph  is  described. 

In  Section  4 the  algorithm  for  generating  the  prime-constraint 
graph  is  described,  and  some  of  the  mathematical  results  underlying 
the  algorithm  are  presented. 


A summary  of  the  results  achieved  and  suggestions  for  future 
work  are  included  in  Section  5. 
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SECTION  2 


BACKGROUND 


A PROBLEM 

'Information- flow  analysis'  [1,2]  is  currently  the  primary 
technique  for  establishing  the  security  of  computer  programs.  The 
ideas  behind  this  approach  are  straightforward:  The  elementary 
information  flows  for  each  program  statement  are  established  first. 
In  general,  if  a variable  x is  a function  of  the  variables 
y1,...,yn,  then  there  is  said  to  be  a flow  from  each  of  the  y's  to 
x.  The  next  step  is  to  take  the  'transitive  closure'  of  the  flow 
relation.  This  means  that  if  there  is  a flow  from  x to  y and  a flow 
from  y to  2,  then  there  is  assumed  to  be  a flow  from  x to  z.  Once 
all  of  the  information  flows  have  been  established,  it  is  then 
simply  a matter  of  determining  whether  any  of  the  flows  produces  a 
security  violation.  In  the  case  of  multi-level  security,  this 
involves  checking  to  see  that  there  is  no  flow  from  a variable  with 
a high  security  level  to  a variable  with  a low  security  level. 

The  claim  that  is  made  for  information-flow  analysis  is  that  if 
a program  has  a flow  violation,  then  that  violation  will  be  exposed. 
The  converse,  however,  is  not  true.  For  a secure  program, 
information-flow  analysis  may  detect  a flow  violation  that,  in  fact, 
is  not  a compromise.  Consider  the  following  simple  program  (in 
which  • denotes  modulo-2  addition): 

Boolean:  a,b,c,d 
b:=a 
c :=a 
d:=b«c 

Information-flow  analysis  establishes  the  following  flows: 

a >b 

a >c 

b >d 

c >d 

a >d 

Now  if  Variable  'a'  is  at  a higher  security  level  than  Variable  'd', 
then  a flow  violation  is  detected  because  there  is  a flow  from  'a' 
to  'd'.  It  turns  out,  however,  that  when  the  assignment  d:sb«c  is 
made,  d is  always  assigned  the  value  'O'  - regardless  of  the  value 
of  a.  ('b'  and  'c'  will  always  be  equal  when  the  assignment  is 


made.)  Under  these  circumstances,  we  would  like  to  say  that  there 
is  no  flow  from  a to  d,  but  conventional  information-flow  analysis 
is  unable  to  accept  that  conclusion. 

The  problem  is  that  information  flow  is  not  transitive.  Flows 
from  x to  y and  from  y to  z do  not  necessarily  imply  a flow  from  x 
to  z.  What  is  needed  is  a more  sophisticated  notion  of  information 
flow,  one  that  does  not  assume  transitivity. 

The  concept  of  a prime  constraint  provides  us  with  just  the 
tool  we  need.  Although  prime  constraints  do  not  deal  explicitly 
with  the  notion  of  information  flow,  they  give  us  something  more 
valuable.  They  tell  us  under  what  circumstances  'deductions'  can  be 
made,  and,  as  we  have  shown  [3],  deductions  are  the  key  to 
determining  whether  or  not  a system  is  secure.  (In  the  example 
above,  knowing  the  value  of  d after  the  last  assignment  is  made  does 
not  permit  us  to  deduce  anything  about  a.) 


OUR  MODEL 

The  model  upon  which  our  approach  is  based  has  already  been 
described  in  earlier  papers  [3,^,5]-  For  reference,  we  review  here 
the  essential  definitions. 

A system  is  asssumed  to  have  associated  with  it  a finite  set  of 
variables,  with  each  variable  ranging  over  a finite  set  of  values. 

A condition  is  an  assignment  of  a value  to  a variable.  A state  is 
any  set  of  conditions  containing  exactly  one  condition  for  each 
variable . 

We  assume  that  each  system  has  a finite  set  of  state 
transitions  which  define  the  allowable  behavior  for  the  system.  A 
simulation  is  any  state  sequence  for  which  every  ordered  pair  of 
consecutive  states  is  a state  transition.  We  place  no  restrictions 
on  the  initial  state  of  a simulation. 

A term  is  any  set  of  conditions  such  that  no  variable  has  all 
its  conditions  in  that  set.  For  a term  t,  statesf t)  denotes  the  set 
of  states  s such  that  for  each  variable  with  conditions  in  t,  s 
contains  one  of  those  conditions.  The  empty  set  is  a term  of 
special  interest  since  states(U)  is  the  set  of  all  states. 
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A clause  is  a finite  (possibly  empty)  sequence  of  terms.  For  a 
clause  x,  seat x)  denotes  the  set  of  state  sequences  w such  that:1 

1.  w is  the  same  length  as  x,  and 

2.  w(i)  is  a member  of  states(x(i) ) . 


CONSTRAINTS 

The  concepts  of  a 'constraint'  and  of  a 'prime  constraint*  have 
already  appeared  in  a number  of  papers  [3, **,5,6, 7].  Although  the 
two  definitions  are  simple,  they  are  somewhat  counter-intuitive 
since  they  deal  with  excluded  state  sequences  (nonsimulations). 

First  of  all,  a constraint  is  any  clause  x such  that  seq(x) 
contains  no  simulations.  A constraint,  in  effect,  represents  an 
incompatibility  among  successive  states  in  a simulation.  We  refer 
to  a constraint  of  length  n as  an  n-place  constraint. 

In  order  to  define  a prime  constraint,  we  must  first  introduce 
the  notion  of  one  clause  'covering'  another.  Clause  x is  said  to 
cover  Clause  y if  and  only  if  there  exists  a (consecutive) 
subsequence  z of  y such  that  x and  z are  the  same  length  and 
states(z(i))Q states(x(i)) . From  this  definition  it  follows  that  if 
Constraint  x covers  Constraint  y,  then  every  state  sequence  excluded 
by  y is  also  excluded  by  x.  (Note  that  any  extension  of  a 
nonsimulation  is  also  a nonsimulation.) 

A prime  constraint  is  simply  any  constraint  that  is  not 
(properly)  covered  by  another  constraint.  A prime  constraint  thus 
may  be  viewed  as  a 'maximally  reduced*  constraint.  The  set  of  tvo- 
place  prime  constraints  has  a special  significance  since  it  is 
equivalent  to  the  set  of  state  transitions.  From  the  standpoint  of 
security,  prime  constraints  are  of  interest  because  they  determine 
precisely  what  'deductions'  may  be  made  in  a system. 

DEDUCTIONS 

Let  us  suppose  that  there  is  a person  with  access  to  a subset 
of  variables  A.  This  means  that  the  person  knows  for  every 


1 For  a sequence  z and  an  integer  i,  z(i)  denotes  the  i'th  component 
of  z. 
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simulation  of  the  system  what  the  conditions  are  for  each  of  the 
variables  in  A.  It  is  not  important  whether  this  access  is  through 
observation  (reading),  modification  (writing),  or  some  combination 
of  the  two. 

Now  consider  a second  subset  of  variables  B which  is  disjoint 
from  A.  We  shall  assume  that  all  of  the  knowledge  that  the  person 
has  about  the  behavior  of  the  variables  in  B is  gained  from  his 
knowledge  about  the  behavior  of  the  variables  in  A and  from  his 
knowledge  about  the  structure  of  the  system.  The  person  has  no 
direct  access  to  any  of  the  variables  in  B. 

We  now  ask  the  following  question:  Under  what  circumstances 
can  access  to  the  variables  in  A be  used  to  deduce  something  about 
the  behavior  of  the  variables  in  B?  Before  answering  that  question, 
we  first  need  to  clarify  what  it  means  to  'deduce  something'.  We 
shall  say  that  access  to  a set  of  variables  A can  be  used  to  deduce 
something  about  a disjoint  set  of  variables  B if  and  only  if, 

There  exist  two  simulations  u and  v,  both  the  same  length,  for 
which  there  is  no  third  simulation  w,  the  same  length  as  u and 
v,  such  that  wA=uA  and  wB=vB.2 

This  requirement  is  a formal  way  of  saying  that  the  pattern  uA  and 
the  pattern  Vg  are  mutually  exclusive.  That  is,  the  presence  of  uA 
in  a simulation  of  length  n excludes  the  presence  of  vB,  and  vice 
versa.  Thus,  a person  observing  the  pattern  uA  in  any  simulation  of 
length  n is  able  to  deduce  that  the  pattern  vfi  could  not  also  have 
occurred.  But  the  person  knows  that  Vg  could  have  occurred  under 
different  circumstances  - for  instance,  if  he  had  observed  vA. 
Observing  u.  in  a simulation  x of  length  n therefore  provides 
additional  information  about  what  patterns  are  possible  for  x0.  in 
particular,  the  observer  now  knows  that  x0  i vB.  (Notice  that  it  is 
not  necessary  for  the  observer  to  know  precisely  what  Xg  is.  It  is 
sufficient  that  he  is  able  to  narrow  the  set  of  possibilities.) 

Having  formalized  the  concept  of  deduction,  we  can  now  answer 
the  question  posed  above. 


^ If  x is  a clause  and  Q a set  of  variables,  then  xg  denotes  the  new 
clause  that  is  obtained  from  x by  removing  all  conditions  not 
belonging  to  a variable  in  Q. 
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Theorem:  Access  to  a set  of  variables  A can  be  used  to 
deduce  something  about  a disjoint  set  of  Variables  B (and 
vice  versa) 

if  and  only  if 


there  exists  a prime  constraint  that  contains  at  least  one 
condition  belonging  to  a variable  in  A,  at  least  one 

! condition  belonging  to  a variable  in  B,  but  no  conditions 

belonging  to  any  other  variables. 3 

| 

So  we  see  that  the  concept  of  deduction  is  intimately  tied  to  the 
concept  of  a prime  constraint.  The  ability  to  determine  the  prime 
constraints  of  a system  gives  us  the  ability  to  determine  the 
deductions  of  a system. 

The  problem  now  is  to  find  a way  of  generating  the  prime 
constraints  of  a system. 


SECTION  3 


THE  PRIME-CONSTRAINT  GRAPH 


REPRESENTING  PRIME  CONSTRAINTS 

Because  the  number  of  prime  constraints  associated  with  a 
system  may  be  infinite,  it  is  not  always  possible  to  simply  list 
them.  But  as  we  show  in  this  section  and  the  next,  it  is  possible 
to  generate  a (finite)  graph,  called  the  prime-constraint  graph, 
that  represents  completely  the  set  of  prime  constraints  for  a 
system. 

To  help  illustrate  the  idea  of  a prime-constraint  graph,  we 
consider  a four-stage  shift  register  as  an  example.  There  are  four 
binary  variables:  a,  b,  c,  and  d.  Now  if  x is  one  of  these 
variables  and  v is  one  of  the  values  'O'  or  * 1 • , then  xv  will  be 
used  to  denote  the  condition  representing  the  assignment  of  v to  x. 
Thus,  the  condition  bl  represents  the  assignment  of  a ' 1 * to 
Variable  b.  The  operation  of  the  four-stage  shift  register  is 
determined  by  its  set  of  two-place  prime  constraints:® 

<{a0}  {b1}>  < { bO } {el )>  <{c0}  {d1}> 

<{a1 } { bO } > <{b1 } {c0}>  <{c1 } {d0}> 

From  these  constraints  the  prime-constraint  graph  depicted  in 
Figure  1 is  generated. 

In  a prime-constraint  graph,  each  arc  is  labelled  with  a term, 
and  thus  each  path  through  the  graph  is  associated  with  a clause. 

The  interpretation  of  the  graph  is  straightforward:  A clause  is  a 
prime  constraint  if  and  only  if  it  is  associated  with  a maximal  path 
in  the  prime  constraint  graph.  The  requirement  that  the  path  be 
maximal  simply  means  that  the  path  must  start  at  a node  with  no 
input  arcs  and  terminate  at  an  node  with  no  output  arcs.  For  the 
graph  shown,  there  are  only  a finite  number  of  maximal  paths.  The 
prime  constraints  associated  with  these  paths  are: 


® As  a notational  convenience,  we  omit  commas  in  our  representations 
of  sets  and  sequences. 
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Figure  1.  Prime-Constraint  Graph  for  Four-Stage  Shift  Register 

<{a0}  {bl }>  <{b0}  {cl >>  <{c0}  {d1}> 

<{a1 } {b0}>  <{b1 } {c0}>  <{c1)  {<10>> 

<{a0}  {}  {cl )>  <{b0}  O td1}> 

<{a1}  {}  {c0}>  <{b1 > {}  {d0}> 

<{a0}  O {}  {d1}> 

<{a1)  {}  {}  {d0}> 

A little  thought  should  convinoe  the  reader  that  these  prime 
constraints  do  indeed  reflect  the  behavior  of  a four-stage  shift 
register.  For  example,  the  prime  constraint  <{b1)  0 (d0}>  says 
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that  if  a state  in  a simulation  contains  a bl,  then  the  state  two 
frames  later  (if  there  is  one)  cannot  contain  a dO,  and  therefore 
must  contain  a dl. 

In  the  next  subsection  we  look  at  what  happens  when  a system 
has  an  infinite  number  of  prime  constraints. 


LOOPS 


It  might  be  supposed  that  a system  with  an  infinite  number  of 
prime  constraints  would  have  to  be  fairly  complicated.  This  is  not 
the  case.  Consider  the  system  with  a single  binary  variable  a = 

{ { aO } {a  1 ) } 5 and  a single  two-place  prime  constraint  <{a0}  {a1}>. 

The  prime-constraint  graph  is  shown  in  Figure  2. 


tal) 
>+ 


0 


Figure  2.  Prime-Constraint  Graph  with  a Loop 


The  notable  feature  of  this  graph  is  the  loop  labelled  with  { ) . 
It  is  this  loop  that  permits  an  infinite  number  of  prime  constraints 
to  be  represented.  A path  from  the  (unique)  starting  node  to  the 
(unique)  terminating  node  may  traverse  the  loop  any  number  of  times 
(including  zero),  with  each  such  traversal  adding  another  {}.  The 
set  of  prime  constraints  thus  forms  the  following  infinite  sequence: 


^ We  have  taken  the  liberty  of  identifying  the  set  of  conditions 
belonging  to  a variable  with  the  variable  itself. 
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< { aO } {a1}> 

<{aO)  {}  {a1}> 
<{aO}  {}  {}  { al } > 


The  interpretation  for  this  sequence  of  prime  constraints  is  simple: 
If  the  value  of  Variable  a is  'O',  then  it  will  always  be  'O'.  And 
conversely,  if  the  value  of  Variable  a is  ' 1',  then  it  must  always 
have  been  ' 1 ' . 

This  example  is  a trivial  one.  In  general,  a prime-constraint 
graph  is  not  restricted  to  a single  loop,  nor  is  a loop  restricted 
to  a single  arc.  As  a result,  some  very  intricate  structures  are 
possible. 


CHECKING  FOR  A DEDUCTION 

At  the  beginning  of  the  last  section,  we  looked  at  the  possible 
information  flows  in  the  following  program: 

Boolean:  a,b,c,d 
b:=a 
c : =a 
d : =bec 

We  convinced  ourselves  that  there  was  no  flow  from  Variable  a to 
Variable  d even  though  a (conventional)  information- flow  analysis 
concluded  that  there  was  such  a flow  and  an  apparent  security 
violation.  An  analysis  of  this  program  based  on  prime  constraints 
eliminates  this  discrepancy. 

Let  us  first  remove  the  inessential  timing  details  of  the 
program  by  converting  it  into  the  closely-related  'flow  diagram' 
shown  in  Figure  3.  It  is  then  a simple  matter  to  derive  a 
specification  of  the  program  in  terms  of  two-place  constraints: 
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Figure  3. 

Flow  Diagram 

<{a0) 

{b1}> 

<{a0} 

{Cl}> 

<{a1 } 

(b0}> 

<{a1  J 

{ cO  l > 

o 

JD 

V 

cO} 

(d  1 } > 

<{b1 

cl} 

Cdl  }> 

<{b0  cl} 

{ dO } > 

<{b1 

cO} 

{d0}> 

The  associated  prime-constraint  graph  is  shown  in  Figure  4. 

Let  us  consider  some  of  the  deductions  possible.  From  the 
prime  constraint  <{b0  cl}  {d0}>  we  see,  among  other  things,  that 
access  to  Variables  b and  d permits  a deduction  about  Variable  c. 
Specifically,  if  the  partial  simulation  in  Figure  5(e)  is  observed, 
then  one  can  deduoe  that  the  partial  simulation  in  Figure  5(b)  did 
not  also  occur.  (By  the  same  token,  if  the  pattern  in  Figure  5(b) 
is  observed,  then  one  can  oonolude  that  the  pattern  in  Pigure  5(a) 
did  not  oocur.) 
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Figure  4.  Prime-Constraint  Graph  for  Program  example 


Returning  to  the  question  of  information  flow  from  Variable  a 
to  Variable  d,  we  note  that  there  is  no  prime  oonstraint  containing 
conditions  for  both  Variables  a and  d and  for  no  other  variables. 
Prom  the  deduotion  theorem  in  Seotion  2,  we  therefore  oonelude  that 


abed 


bed 


Frame  1 : 
Frame  2: 


(a) 


cl 


(b) 


Figure  5.  Mutually-Exclusive  Patterns 

access  to  Variable  d does  not  permit  a deduction  about  Variable  a 
(and  vice  versa).  So  we  see  that  an  analysis  of  the  above  program 
based  on  prime  constraints  is  consistent  with  the  conclusion  reached 
earlier  that  Variable  a is  not  compromised  by  access  to  Variable  d. 

We  might  note  that  access  to  Variable  d does  tell  us  something 
, interesting.  From  the  prime  constraint  <{}  {}  {d1}>,  it  follows 

that  if  a dl  appears  in  a simulation,  then  there  could  not  have 
been  two  or  more  states  preceding  the  state  with  the  dl.  In  other 
words,  a dl  may  appear  in  only  the  first  or  second  state  of  a 
simulation.  The  fact  that  a dl  may  appear  at  all  reflects  the 
possibility  that  a simulation  may  be  initialized  with  a dl , or  may 
be  initialized  with  a bO  and  cl  or  a bl  and  cO. 


USING  THE  TOOL 

pegraph  is  the  name  of  a LISP  program^  running  on  the  RADC 
(Rome  Air  Development  Center)  Multics  time-sharing  system.  It 
accepts  as  input  a system  specification  in  the  form  of  two 
arguments:  (1)  a set  of  variables  and  (2)  a set  of  two-place 
constraints.  It  produces  as  output  the  prime-constraint  graph  of 
the  system.  Note  that  it  is  not  necessary  for  the  two-place 
constraints  to  be  prime,  pegraph  will  automatically  generate  the 
two-place  prime  constraints  in  the  course  of  constructing  the 
prime-constraint  graph. 


^ Appendix  A contains  a description  of  each  of  the  modules 
comprising  pograph,  while  Appendix  B contains  a listing  of  the 
program. 
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To  illustrate  how  pcgraph  is  used,  we  consider  the  example  in 
the  preceding  subsection.  The  first  argument,  the  set  of  variables, 
is  expressed  as  a list  of  lists: 

((aO  al ) (bO  bl)  (cO  cl)  (dO  dl)) 

Parentheses  are  used  exclusively  since  this  is  the  only  grouping 
symbol  recognized  by  LISP.  Spaces  act  as  separators.  The  program 
treats  the  conditions  aO,  al,  bO,  bl,  cO,  cl,  dO,  and  dl  as  'atomic 
symbols'  and  does  not  attempt  to  analyze  the  individual  characters 
making  up  such  a symbol.  Thus,  the  fact  that  aO  and  al  both  contain 
an  'a'  and  the  fact  that  bl  and  cl  both  contain  a '1'  are  totally 
ignored.  What  is  important  is  the  grouping  of  conditions.  Because 
aO  and  al  are  grouped  together  in  a sublist,  they  are  interpreted  as 
alternative  conditions  of  a single  (binary)  variable,  and  similarly 
for  bO  and  bl,  cO  and  cl,  and  dO  and  dl.  The  only  restriction  on 

the  choice  of  symbols  for  conditions  is  that  no  symbol  may  appear  in 

more  than  one  sublist.  This  requirement  reflects  the  fact  that  a 
condition  is  associated  with  a unique  variable. 

The  second  argument,  the  set  of  two-place  constraints,  is 
expressed  as: 

(((aO)  (bl))  ((al)  (bO) ) ((aO)  (cl))  ((al)  (cO)) 

((bO  cO)  (dl))  ((bl  cl)  (dl))  ((bO  cl)  (dO))  ((bl  cO)  (dO))) 

Each  two-place  constraint  is  of  the  form:  ((conditions) 

(conditions)).  The  first  set  of  conditions  represents  the  first 
term  of  the  constraint , and  the  second  set  of  conditions  the  second 
term.  The  ordering  of  the  two  terms  for  a constraint  is  clearly 
important,  but  the  ordering  of  conditions  within  a term  and  the 
ordering  of  constraints  is  immaterial. 

Before  invoking  pcgraph,  it  is  useful  to  first  create  two 
atomic  symbols,  one  whose  value  is  the  set  of  variables  and  the 
other  whose  value  is  the  set  of  two-place  constraints.  (This  is 
most  easily  done  using  the  'setq'  function.)  If  we  let  V be  the 
first  atomic  symbol  and  C the  second,  then  pcgraph  is  invoked  by  the 
following  command  in  the  LISP  environment: 

(pograph  V C) 

When  pcgraph  terminates,  it  will  type  out  a list  of  symbols 
representing  all  the  nodes  of  the  prime-constraint  graph  exoept  for 
the  unique  starting  node  BEND  (for  Back  BID)  and  the  unique 
terminating  node  PEND  (for  Front  END).  (The  prime-aonstraint  graphs 
given  earlier  were  drnwn  with  multiple  starting  nodes  and  multiple 
terminating  nodes  merely  for  convenience.)  For  our  example  there 
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are  five  nodes,  excluding  BEND  and  FEND,  and  so  pcgraph  upon 
terminating  will  type  a list  something  like: 


(n0123  n0120  n0060  n0043  n0040) 


These  character  strings  are  internally  generated  and  have  no 
significance  other  than  to  provide  unique  names  for  the  nodes, 


In  order  to  obtain  the  arcs  of  the  prime-constraint  graph,  the 
user  types: 


(expand  ARCS) 


The  program  will  then  return  with  a list  of  arcs.  For  the  example 
being  considered  this  list  might  look  like: 


( (a0129 

(a0128 

U0127 

(a0126 

(a0122 

(a0121 

(aOIIO 

(a0108 

(a0107 

(a0064 

(a0105 

(a0106 

(a0109 

(aOI 17 

(a0124 

( aO 1 25 


nil  back  n0060  fore  n0120) 
(bl  cl)  back  BEND  fore  n0120) 
(bl  cO)  back  BEND  fore  n0123) 
(cl  bO)  n0060  fore  FEND) 

(dl ) back  n0120  fore  FEND) 

(bO  cO)  back  BEND  fore  n0120) 
(bO)  back  n0043  fore  FEND) 

(cO)  back  n0043  fore  FEND) 

(a  1 ) back  BEND  fore  n0043) 
nil  back  BEND  fore  n0060) 

(aO)  back  BEND  fore  n0040) 
(cl)  back  n0040  fore  FEND) 

(bl)  back  n0040  fore  FEND) 

(cO  bl)  back  n0060  fore  FEND) 
(bO  cl)  back  BEND  fore  n0123) 
(dO)  back  n0123  fore  FEND)) 


Each  line  represents  an  arc.  The  first  character  string  in  a line 
is  the  name  of  the  arc.  As  with  nodes,  this  name  is  internally 
generated  and  has  no  significance.  The  second  character  string 
represents  the  term  associated  with  the  arc.  And  the  remaining 
strings  indicate  the  two  nodes  connected  by  the  arc.  The  initial 
node  follows  the  word  'back'  and  the  terminal  node  follows  the  word 
'fore'.  With  this  interpretation,  a check  will  show  that  the  nodes 
and  arcs  above  correspond  to  the  graph  in  Figure  4. 


The  reader  now  has  the  background  necessary  to  begin  using 
pcgraph.  The  next  section  is  intended  for  those  who  want  to  learn 
about  the  algorithm  underlying  pograph. 
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SECTION  4 
THE  ALGORITHM 


OVERVIEW 

The  algorithm  for  generating  the  prime-constraint  graph  of  a 
system  consists  of  three  phases:  (1)  Initialize,  (2)  Generate,  and 
(3)  Update.  The  major  task  of  the  Initialize  phase  is  to  construct 
an  initial  graph  from  which  the  second  phase  proceeds.  In  this 
construction,  each  two-place  constraint  supplied  as  input  is 
represented  by  a pair  of  arcs.  In  the  Generate  phase  a technique 
known  as  'resolution'  is  used  to  enlarge  the  graph  to  the  point 
where  every  prime  constraint  (of  arbitrary  length)  is  represented  by 
a path  from  the  (unique)  starting  node  to  the  (unique)  finishing 
node.  This  enlarged  graph,  however,  also  contains,  in  general, 
paths  corresponding  to  constraints  that  are  not  prime.  The  purpose 
of  the  Update  phase  is  to  eliminate  these  'non-prime'  paths.  The 
result  is  a graph  in  which:  (1)  every  path  from  the  starting  node  to 
the  finishing  node  corresponds  to  a prime  constraint  and  (2)  every 
prime  constraint  corresponds  to  such  a path. 

Before  discussing  the  three  phases,  we  must  first  introduce 
three  concepts  that  will  allow  us  to  state  a necessary  and 
sufficient  condition  for  a clause  to  be  a prime  constraint. 


PRIME  IMPl  ANTS 

The  notion  of  a 'prime  implieant'  is  familiar  to  anyone  who  has 
studied  switching  theory.  First  of  all,  an  implieant  of  a set  of 

(states  0 is  just  a term  t such  that  states(t)CQ.  A prime  implieant 
of  Q is  any  implieant  of  Q not  covered  by  a 'larger'  implieant. 

One  of  our  principal  uses  for  prime  implicants  will  be  as  a 
convenient  representation  for  an  arbitrary  set  of  states.  Consider 
a system  in  which  the  set  of  variables  is  {{aO  al}  {bO  bl  b2} 

{cO  el}}.  Por  the  set  of  states 

{(aO  bO  cO)  {aO  bO  cl}  {aO  bl  eO}  {aO  bl  cl}  {aO  b2  cl)  {al  b2  cl}} 
we  have  the  following  set  of  prime  implloants: 

{{aO  bO  bl}  (b2  cl}  {aO  cl}} 
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This  set  provides  a representation  that  is  equivalent  to  the  listing 
of  states. 

In  what  follows,  we  will  be  using  two  binary  operations  on  sets 
of  prime  implicants.  If  A and  B are  each  a set  of  prime  implicants, 
then  sum ( A . B ) denotes  the  set  of  prime  implicants  for  states(A)U 
states(B),  and  product(A.B)  denotes  the  set  of  prime  implicants  for 
states(A) D states(B) J For  the  choice  of  variables  given  above, 

sum( { {aO  bl  b2}  {bl  cl}}  { { bO } } ) = {{aO}  {bO}  { bO  bl  cl}} 
product( { { aO } {bO  b2}}  { { al } {bl } } ) = { { al  bO  b2}  {aO  bl}}. 


FEX  AND  BEX 

Consider  the  clause  z = <{a0  bl}  {}>  from  the  four-stage 
shift-register  described  in  Section  3-  We  are  interested  in  the  set 
of  states  s such  that:  for  each  state  sequence  w in  seq(z),  ws  is 
not  a simulation.  There  are  eight  such  states: 

{{aO  bO  cl  dO}  {aO  bO  cl  dl}  {aO  bl  cl  dO}  {aO  bl  cl  dl } 

{al  bO  cl  dO}  {al  bO  el  dl}  {al  bl  cl  dO}  {al  bl  cl  dl}} 

The  result  of  appending  any  one  of  these  states  to  the  front  end  of 

any  state  sequence  in  seq(z)  is  a nonsimulation.  Furthermore,  these 
are  the  only  states  with  this  property.  For  example,  if 
{aO  bO  cO  dl}  is  appended  to  the  front  end  of  <{a0  bl  cO  dl} 

{aO  bO  cl  d0}>,  which  is  in  seq(z),  the  result  is  a simulation.  If 
we  now  convert  the  above  set  of  states  into  its  equivalent 
representation  as  a set  of  prime  implicants,  we  get  {{cl}}.  This 
set  of  prime  implicants  is  known  as  fex(z)  (for  Xo^wards  exclusion) . 
As  might  be  expected,  there  is  also  a dual  concept  for  the  back  end 
of  a clause.  For  the  same  clause  z,  bex(z)  = {{aO}}. 


7 The  'states'  function  defined  earlier  for  a single  term  is 
extended  to  a set  of  terms  in  the  natural  way.  For  a set  of  terms 
A , 

states(A)  = U states(t) 
tCA 


For  two  seta  of  terms  A and  B,  we  shall  say  that  A covers  B if  and 
only  if  states(A) 2 states(B) . 
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Our  interest  in  fex  and  bex  is  motivated  by  an  Important  result 
that  provides  us  with  a necessary  and  sufficient  condition  for  a 
clause  to  be  a prime  constraint. 

Theorem:  A clause  z of  length  n is  a prime  constraint  if 
and  only  if  the  following  three  conditions  are  satisfied 
for  1.£i£n : ® 

1.  z(i)  is  a member  of  sum(fex(z-(i) ) ,bex(z+(i) ) ) . 

2.  z(i)  is  a member  of  fex(z~(i))  only  for  i=n. 

3.  z(i)  is  a member  of  bex(z+(i))  only  for  1=1. 

The  first  condition  says,  in  effect,  that  no  term  of  z can  be 
enlarged  without  yielding  a non-constraint.  The  second  condition 
says  that  z cannot  be  shortened  on  the  front  end  without  producing  a 
non-constraint.  And  the  third  condition  says  that  z cannot  be 
shortened  on  the  back  end  without  yielding  a non-constraint. 

To  illustrate  the  preceding  theorem  we  consider  three  clauses 
from  our  shift-register  example.  Shown  in  Figures  6 through  8 are 
the  fex's  and  bex's  for  the  three  clauses.  For  the  clause  <{a0)  {} 
{c1}>  we  see  that  all  three  of  the  conditions  in  the  theorem  are 
satisfied  for  each  of  the  three  terms,  and  we  conclude  that  this 
clause  is  a prime  constraint.  For  the  clause  <{a0)  {al}  { c 1 } > , 
however,  we  see  that  Condition  1 is  not  satisfied  for  i=2  since  {al} 
is  not  a member  of  sum(fex(<{aO}>) ,bex(<{c1 }>) ) . And  for  the  clause 
<U  (bO)  {c1}>  we  see  that  Condition  3 ie  not  satisfied  for  i*2 
since  {bO}  is  a member  of  bex(<{cl}>)  but  141.  We  conclude  that 
neither  of  theue  last  two  clauses  is  a prime  constraint. 


MODES  AND  ARCS 

Throughout  the  construction  of  the  prime-constraint  graph,  we 
shall  be  dealing  with  a changing  set  of  ARCS  and  a changing  set  of 
NODES.  A node  n is  defined  by  two  sets  of  prime  implicants,  denoted 
FEX(n)  and  BEX(n).  There  are  two  nodes  of  special  Interest,  BEND 
(for  Back  END)  and  FEND  (for  Front  END),  where, 


8 z"(i)  denotes  the  maximal  subclause  of  z preceding  the  i’th  term. 
*♦(1)  denotes  the  maximal  subclause  of  z following  the  i'th  term. 
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Figure  7.  Fex's  and  Bex's  for  z = <{a0}  tal}  {cl}> 


FEX(BEND)  r {} 
BEX (BEND)  = {{}} 


FEX(FEND)  = {{}} 
BEX (FEND)  s U 


An  arc  a is  defined  by  two  nodes  and  a tern,  denoted,  respeotively, 
BACK(a) , FORE (a) , and  TERH(a) . 

The  interrelationship  between  nodes  and  arcs  is  expressed  by 
five  properties  that  are  preserved  at  every  step  of  the  algorithm: 


*'*■■*; 
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Figure  8.  Fex's  and  Bex's  for  z = <{}  {bO}  Cel > > 


Property  1:  For  each  node  n and  for  each  clause  z 
associated  with  a path  leading  from  BEND  to  n,  fex(z) 
covers  FEX(n). 

Property  2:  For  each  node  n and  for  each  clause  z 
associated  with  a path  leading  from  n to  FEND,  bex(z) 
covers  BEX(n). 

Property  3s  For  each  arc  a,  TERM(a)  is  a member  of 
sum(FEX(BACK(a) ) , BEX (FORE (a) ) ) . 

Property  4s  For  anch  arc  a,  TERM(a)  is  a member  of 
FEX(BACK(a))  only  when  FORE (a)  s FEND. 

Property  5:  For  each  arc  a,  TERH(a)  is  a member  of 
BEX(FORECa) ) only  when  BACK (a)  x BEND. 

We  should  add  that  when  the  algorithm  terminates  the  following 
two  properties,  which  are  stronger  versions  of  Properties  1 and  2, 
will  hold: 

Property  1 ' : For  each  node  n and  for  each  olause  z leading 
from  BEND  to  n,  FEX(n)  * fex(z). 

Property  2':  For  each  node  n and  for  each  clause  z leading 
from  n to  FEND,  BEX(n)  * bex(z). 
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We  then  see  that,  at  termination,  Properties  3,  4,  and  5 guarantee 
that  each  clause  associated  with  a path  leading  from  BEND  to  PEND  is 
a prime  constraint.  (Recall  the  theorem  earlier  in  this  section.) 


i 


-j 

i 


THE  INITIALIZE  PHASE 

In  discussing  the  algorithm,  it  will  be  helpful  to  consider  the 
following  simple  example: 

variables  = {{aO  al } {bO  bl)  {cO  cl}  {dO  dl } {eO  el}} 


constraints  = {<{a0  bO}  { el } > 

<{c0}  {dl }> 

<{a0}  {el }> 

<{e0}  {dl }>  } 

The  first  step  of  the  algorithm  is  to  construct  a graph  in 
which  each  of  the  two-place  constraints  supplied  as  an  input  is 
represented  by  a path.  Let  z=<t1  t2>  be  such  an  input  constraint. 
Because  z is  a constraint,  it  must  be  that  states(tl)^ 
states(bex(<t2>) ) and  states(t2)  C states(fex(<t1>)) . We, 
therefore,  construct  this  two-arc  path  to  represent  z: 

BEND  tl  n t2  FEND 

+ — — 

where  BEX(n)  = {tl}  and  FEX(n)  = {t2}.  Note  that  in  constructing 
this  subgraph  we  are  preserving  Properties  1-5. 

When  this  construction  is  applied  to  each  of  the  two-place 
constraints  in  our  example,  we  get  the  initial  graph  shown  in 
Figure  9 where, 

BEX(nl)  = UaO  bO}}  FEX(nl)  = {{cl}} 

BEX(n2)  = {{cO}}  FEX(n2)  = {{dl}} 

BEX(n3)  = UaO}}  FEX(n3)  = ttel}} 

BEX(n4)  = {{eO}}  FEX(n4)  » {{dl}} 

Once  the  Initialize  phase  of  our  algorithm  is  completed,  the 
techniques  of  'resolution'  and  'extension'  are  used  to  generate  the 
additional  nodes  and  arcs  needed  to  represent  an  arbitrary  prime 
constraint. 


y" 
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{eO} 
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■f— 

— >+ — 

>+ 

Figure  9.  Initial  Graph 


RESOLUTION 


Resolution,  also  known  as  consensus,  is  a technique  from 
propositional  logic  and  switching  theory  for  generating  the  prime 
implicants  of  a Boolean  expression.  (A  variation  of  this  technique 
is  used  in  the  implementation  of  the  sum  and  product  operations.)  We 
show  here  how  a natural  extension  of  resolution  can  be  used  to 
generate  the  prime  constraints  of  a system.  To  define  this  new 
concept,  we  must  first  introduce  the  'gib*  and  'lub'  operations. 

Suppose  that  tl  and  t2  are  terms  such  that  the  intersection  of 
states(tl)  and  states (t2)  is  nonempty.  Under  these  circumstances, 
tl  and  t2  have  a greatest  lower  bound  with  respect  to  the  'covers'' 
partial  order.  This  bound,  which  is  denoted  glb(t1,t2),  turns  out 
to  be  the  unique  prime  lmplicant  of  states(tl) 0 states(t2) . In  the 
case  where  the  intersection  of  states(tl)  and  states(t2)  is  empty, 
the  gib  of  tl  and  t2  simply  does  not  exist. 

Consider  a system  in  which  the  set  of  variables  is  {{aO  al  a2} 
{bO  b1}}.  We  then  have,  for  example, 

glb({a0},{b1})  s {aO  bl) 
glb({a0},{a1  a2})  does  not  exist 
glb({aO  a1),(a1  a2>)  * {al} 
glb({) ,{a1  a2  bO})  * {al  a2  bO}. 
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Now  let  tl  and  t2  be  two  arbitrary  terms.  The  least  upper 
bound  (with  respect  to  the  'covers'  partial  order)  of  tl  and  t2 
always  exists  and  Is  denoted  Iub(t1,t2).  The  lub  of  tl  and  t2  is 
the  unique  prime  implicant  of  those  states  s such  that  every 
condition  in  s appears  either  in  a state  of  states(tl)  or  in  a state 
of  states(t2).  Returning  to  the  set  of  variables  given  Just  above, 
we  have, 

lub( (aO) , (bl } ) = {} 
lub({aO} ,{a2})  a {aO  a2} 


Iub({a0},{a1  a2})  = {} 
lub({aO  al) ,{a1  a2})  = {} 


lub({aO  b1),{a1  bl))  = {aO  al  bl) 
lub( { } , { al  bO})  = {}. 

Let  us  suppose  now  that  there  are  two  clauses  x and  y,  both  of 
length  n,  and  a variable  v such  that  for  some  min: 

1.  x(m)Hv  and  y(m)Dv  are  incomparable.  That  is, 
x(m)flv£y(m)nv  and  y(m)Hv£ x(m)Ov. 

2.  glb(x(m)-v,y(m)-v)  exists. 

3.  glb(x(i) ,y(i))  exists  for  liiln  and  i*m. 

The  clause  z,  of  length  n,  defined  as  follows  is  then  a resolvent  of 
x and  y: 


1.  z(m)  s lub(x(m)flv,y(m)nv)  U glb(x(m)-v,y(m)-v) 


2.  z(i)  = glb(x(i) ,y(i))  for  1£iln  and  i*m. 


To  illustrate  this  idea,  consider  the  clauses 
x * <{a0)  {aO  bO)  {}> 
y * <{a0  a2  bl)  {a2)  (al  b0)> 

over  the  variables  {aO  al  a2)  and  {bO  bl).  Let  m * 2 and  let  v » 
(aO  al  a2).  We  then  see  that, 
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x(2)Ov  x {aO} 
y(2)flv  x {a2} 

lub(x(2)nv,y(2)nv)  x {aO  a2) 
x(2)-v  x {bO} 
y(2)-v  = {} 

glb(x(2)-v,y(2)-v)  x {bO} 
glb(x(  1 ) ,y(1 ))  = UO  bl } 
glb(x(3) ,y(3))  x {al  bO}. 

The  clause  z x <{aO  bl)  {aO  a2  bO}  {al  bO}>  is  thus  a resolvent  of  x 
and  y. 

The  essential  properties  of  a resolvent  are  contained  in  the 
following  result. 

Theorem:  If  z is  a resolvent  of  the  clauses  x and  y,  then, 

1.  seq(z)  2 seq(x) U seq(y) 

2.  seq(z)  2 seq(x) 

3.  seq(z)  2 seq(y) 

This  result  is  primarily  of  interest  to  us  for  the  caae  where  both  x 
and  y are  constraints. 

Corollary:  If  z is  a resolvent  of  the  oonatraints  x and  y, 
then , 

1.  z is  also  a constraint. 

2.  z is  not  oovered  by  x. 

3.  * is  not  oovered  by  y. 

Resolution  can  thus  be  used  to  generate  new  oonatraints  from 
existing  ones. 
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EXTENSION 


As  we  have  Just  seen,  resolution  can  be  applied  only  to  clauses 
of  the  same  length,  and  then  only  when  the  terms  to  be  resolved  are 
corresponding  terms.  These  restrictions  thus  prevent  the 
constraints  <{a0}  { bl } > and  < { bO } { c 1 } > in  our  shift-register 
example  from  being  resolved.  In  resolving  constraints,  however,  we 
can  take  advantage  of  a useful  property: 

Property:  Any  extension  of  a constraint  is  also  a 
constraint. 

Let  us  now  append  a { } to  the  front  end  of  the  constraint 

<{a0}  { bl } > and  a {}  to  the  back  end  of  the  constraint  < { bO } {c1}>. 

The  two  new  constraints, 

<{a0}  {bl } {}> 
and 

<U  {bO}  {c1}>, 

can  then  be  resolved  (using  the  bl  and  bO)  to  produce  the  new 
constraint , 

<{a0}  {}  {cl }>. 

It  can  be  shown  that,  together,  resolution  and  extension  are 
sufficient  to  generate  any  prime  constraint  of  a system  from  the  set 
of  two-place  constraints. 


FEX'S  AND  BEX'S  OF  A RESOLVENT 

Let  z be  a resolvent  of  the  clauses  x and  y.  We  wish  to  know 
what  the  relationship  is  between  the  fex's  and  bex's  of  z and  the 
fex's  and  bex's  of  x and  y.  As  it  turns  out,  that  relationship  is 
fairly  interesting. 

Theorem:  If  x and  y are  clauses  of  length  n,  and  z is 
obtained  from  x and  y by  resolving  a variable  in  the  m'th 
terms  of  x and  y,  then, 

1.  fex(z-(i))  oovers  sum(fex(x“(i)) ,fex(y”(i) ) ) 
for 

2.  fex(z-(i))  covers  product (fex(x_(i)) ,fex(y“(i))) 
for  m<l£n. 


! 


3.  bex(z+(i))  covers  sum(bex(x+(i) ) ,bex(y+(i) ) ) 
for  m£l£n. 

4.  bex(z+(i))  covers  product(bex(x+(i))  ,bex(y*(i))) 
for 

So  we  see  that  the  relationship  between  fex(z-(i)),  fex(x"(i)),  and 
fex(y-(i))  depends  upon  whether  i£p  or  i>m,  and  that  the 
relationship  between  bex(z+(i)) , bex(x+(D),  and  bex(y+(i))  depends 
upon  whether  12m  or  i<m. 

Let  us  consider  the  clauses  xa<{a0}{b1 }{)>  and  ys<{}{b0}{c1}> 
from  the  shift- register  example.  As  we  noted  earlier,  the  clause 
z=<{aO} { Hel }>  can  be  obtained  from  x and  y by  resolving  the 
variable  {bO  bl } in  the  second  terms  of  x and  y.  The  above  theorem 
can  be  checked  by  comparing  the  fex's  and  bex's  for  x,  y,  and  z as 
given  in  Figures  10  and  11. 
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Pigure  10.  Fex's 

for  Clauses 

x,  y,  and  z 

THE  GENERATE  PHASE 

In  the  Generate  phase,  the  ideas  of  the  preceding  three 
sections  are  used  to  enlarge  the  graph  produced  by  the  Initialize 
phase  so  that  every  prime  constraint  (of  arbitrary  length)  is 
represented  by  a path  from  BEND  to  PEND.  The  procedure  consists  of 
a series  of  resolutions. 


£ 
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bex(x+(i)) 


bex(y+(i)) 


sum(bex(x+(i)) ,bex(x+(i))) 
product(bex(x+(i)) ,bex(y+(i))) 

bex(z+(i)) 


Figure  11.  Bex's  for  Clauses  x,  y,  and  z 


The  first  step  in  a resolution  is  to  find  a pair  of  arcs  a and 
b in  the  current  graph  such  that  for  some  variable  v: 


1.  TERM(a)nv  and  TERM(b)flv  are  incomparable 


2.  glb(TERM(a)-v,TERM(b)-v)  exists 


The  next  step  is  to  find  two  paths  Pa  and  Pb  in  the  current  graph 
such  that: 


3.  Pa  and  Pb  are  the  same  length 


4.  Arc  a and  Arc  b appear  in  the  same  relative  positions  of  Pa 
and  Pb,  respectively. 


5.  Either  Pa  or  Pb  begins  at  BEND,  and  either  Pa  or  Pb  ends  at 
FEND. 


For  each  pair  of  arcs  a'i(a  and  b'*b  that  appear  in  the  same 
relative  positions  of  Pa  and  Pb,  respectively, 
glb(TERM(a'),TERM(b'))  exists. 


If  all  six  requirements  are  met,  then  a new  path  Pc  is 
tentatively  constructed.  (It  will  be  added  to  the  graph  only  if 
certain  additional  requirements  are  satisfied.)  In  the  construction 
each  pair  of  corresponding  nodes  in  Pa  and  Pb  is  transformed  into  a 
node  of  Pc,  and  each  pair  of  corresponding  arcs  in  Pa  and  Pb  is 
transformed  into  an  are  of  Pc.  The  rules  for  the  creation  of  this 
new  path  are  as  follows: 
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Corresponding  nodes  m and  n in  Pa  and  Pb  that  precede  Arcs  a 
and  b are  transformed  into  the  node  q where, 


FEX(q)  = sum(FEX(m) ,FEX(n) ) 
BEX(q)  = product(BEX(m) ,BEX(n) ) 


Corresponding  nodes  m and  n in  Pa  and  Pb  that  follow  Arcs  a 
and  b are  transformed  into  the  node  q where, 


FEX(q)  = product(FEX(m) ,FEX(n) ) 


BEX(q)  s sum(BEX(m) ,BEX(n) ) 


3.  Arcs  a and  b are  transformed  into  the  arc  c where, 


TERM(c)  = lub(TERM(a)Tlv,TERM(b)Ov) 
U glb(TERM(a)-v,TERM(b)-v) 


BACK(c)  is  the  result  of  transforming 
BACK(a)  and  BACK(b) . 


FORE(c)  is  the  result  of  transforming 
FORE (a)  and  FORE(b). 


Corresponding  arcs  a'rfa  and  b'ib  in  Pa  and  Pb  are 
transformed  Into  the  arc  c'  where, 


TERM(c')  = glb(TERM(a' ) ,TERM(b' ) ) 


BACK (o' ) is  the  result  of  transforming 
BACK(a')  and  BACK(b'). 


FORE (o')  is  the  result  of  transforming 
FORE(a')  and  FORE(b'). 


Having  constructed  Pc,  we  must  now  check  to  see  if  Properties 
1-5  (on  p.  21)  are  satisfied  by  the  nodes  and  arcs  of  Pc.  In  the 
case  of  Properties  1 and  2,  our  method  of  construction,  together 
with  the  theorem  in  the  preceding  subsection,  guarantees  that  these 
two  properties  will  be  satisfied.  For  Properties  3,  4,  and  5, 
however,  there  is  no  suoh  assurance,  and  these  properties  must  be 
individually  cheoked  for  eaoh  arc  of  Pc.  If  Properties  3>  4,  and  5 
are  satisfied,  then  the  path  Pc  is  added  to  the  graph.  (Note  that 
some  parts,  or  all,  of  Po  may  already  exist.) 


The  process  of  resolution  Just  described  is  repeated  for  other 
arcs  and  other  paths.  The  prooess  continues  until  no  new  nodes  and 


no  new  arcs  can  be  created.  At  that  point  the  Generate  phase  is 
terminated. 


To  illustrate  the  process  of  resolution,  let  us  return  to  the 
example  considered  for  the  Initialize  phase.  Let  a be  the  arc, 


and  let  v be  the  variable  {cO  cl}.  We  see  immediately  that 
TERM(a)f)v  and  TERM(b)nv  are  incomparable,  and  that 
glb(TERM(a)-v,TERM(b)-v)  exists.  Now  let  Pa  be  the  path  consisting 
of  Just  Arc  a,  and  Pb  the  path  consisting  of  just  Arc  b.  We  observe 
immediately  that  Requirements  3,  4,  and  5 are  satisfied. 

Requirement  6 is  trivially  satisfied  because  there  are  no  other  arcs 
besides  a and  b.  In  constructing  the  path  Pc,  the  pair  of  nodes  nl 
and  BEND  are  transformed  into  the  node  nl , and  the  pair  of  nodes 
FEND  and  n 2 are  transformed  into  the  node  n 2.  (Recall  that 
FEX(BEND)  = U,  BEX(BEND)={ { } } , FEX(FEND)={  ( } } , and  BEX(FEND)s{ ) . ) 

Arcs  a and  b are  transformed  into  the  arc  c where  TERM(c)={}, 
BACK(c)=n1,  and  F0RE(c)=n2.  The  result  is  the  path  Pc: 


Since  FEX(n1 )={ {cl }}  and  BEX(n2)s{ {cO} } , we  see  that  Properties  3 
4,  and  5 are  satisfied.  And  so  the  arc  comprising  Pc  is  added  to 
our  graph. 


The  graph  at  the  end  of  the  Generate  phase,  when  all  possible 
resolutions  have  been  exhausted,  is  shown  in  Figure  12. 


THE  UPDATE  PHASE 


Although  the  graph  produced  at  the  end  of  the  Generate  phase 
has  a path  for  every  prime  constraint,  the  converse  is  not 
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Figure  12.  Graph  at  End  of  Generate  Phase 


necessarily  true.  It  is  possible  for  a path  from  BEND  to  FEND  to 
represent  a constraint  that  is  not  prime.  The  graph  in  Figure  12 
provides  an  illustration  of  this  point.  Consider  the  two  paths: 
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nl 
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FEND 
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The  constraints  associated  with  these  two  paths  are 

<{a0  bO}  {}  {d1}>  and  <{a0}  {}  {d1}>.  Since  the  first  constraint  is 


properly  covered  by  the  second, 
prime . 


be 
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The  problem  stems  from  the  fact  that  the  FEX  of  a node  may  not 
be  equal  to  the  fex  of  each  path  leading  from  BEND  to  that  node. 

• And  similarly,  the  BEX  of  a node  may  not  be  equal  to  the  bex  of  each 

path  leading  from  that  node  to  FEND.  In  the  case  of  our  example, 
BEX(nl)  = {{aO  bO } } but  bex(<{}  {dl } > ) = { { aO } ) . The  purpose  of  the 
Update  phase  is  to  eliminate  this  discrepancy. 

Suppose  that  PI  and  P2  are  two  paths  in  the  current  graph.  PI 
begins  at  BEND  and  ends  at  Node  m,  and  is  associated  with  the  clause 
x.  (See  Figure  13.)  P2  has  a terminal  node  of  n,  and  is  associated 
with  the  clause  z.  Now  suppose  that  x and  z are  the  same  length, 
and  that  x covers  z.  It  follows  that  fex(z)  covers  fex(x).  From 
Property  1 we  know  that  fex(x)  covers  FEX(m),  and,  therefore,  fex(z) 
must  cover  FEX(m).  The  question  is  whether  or  not  FEX(n)  covers 
FEX(m).  If  it  does,  then  there  is  no  problem.  If,  however,  FEX(n) 
does  not  cover  FEX(m) , then  it  is  necessary  to  change  the  terminal 
node  of  P2. 


BEND  x m 

PI:  + >+  . . . + ->+ 


z n 

P2 : + >+  . . . + — >+ 


Figure  13-  Updating  a FEX 


The  transformation  is  represented  in  Figure  14.  A new  node  n' 
is  created  where  FEX(n')  s sum(FEX(n) ,FEX(m) ) and  BEX(n')  = BEX(n). 
(Note  that  n'  may  be  an  already  existing  node.)  The  last  arc  of  P2 
is  replaced  by  an  arc  leading  to  n',  and  emergent  arcs  are  added  to 
n'  to  'duplicate'  the  emergent  arcs  of  n.  Once  the  transformation 
is  completed,  the  newly-created  arcs  are  checked  to  see  that  they 
satisfy  Properties  3,  4,  and  5.  Any  ares  not  satisfying  these 
properties  are  deleted.  Finally,  any  arc  or  node  that  is  no  longer 
part  of  a path  leading  from  BEND  to  FEND  is  removed.  This  entire 
process  is  repeated  until  no  further  'updatings'  of  FEX's  are 
possible.  A similar  procedure  is  then  performed  for  the  BEX's  of 
nodes.  When  this  task  is  completed,  the  algorithm  terminates,  and 
the  resulting  graph  is  the  prime-constraint  graph  for  the  system 
that  was  supplied  as  input. 
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Figure  14.  Splitting  a Node 


To  illustrate  the  process  of  updating,  we  return  to  our  sample 
system.  Let  PI  and  P2  be  the  two  paths: 


BEND  {aO}  n3 
pi:  •< >+ 

BEND  {aO  bO}  nl 
P2:  «- >♦ 


Since  PI  and  P2  meet  the  necessary  requirements  and  since 

FEX(n1 )={ {cl } } does  not  cover  FEX(n3)s{{e1}} , we  proceed  with  an 

update.  A new  node  n5  is  created  where  FEX(n5)  = 

sum( {{cl }} , { {el } } ) = {{cl}  {el}}  and  BEX(n5)  = BEX(nl)  = {{aO  bO}}. 

After  the  required  arcs  are  attached  to  n5  and  after  the  last  (nnd 

only)  arc  of  P2  is  deleted,  we  have  the  structure  shown  in 

Figure  15.  We  see  that  Node  nl  and  its  two  emergent  arcs  are  no 

longer  contained  in  paths  leading  from  BEND  to  FEND,  and  so  they  are 

deleted. 

We  next  consider  the  following  two  paths: 


n3 

{} 

n4 

{dl} 

FEND 

n5 

{} 

n2 

{dl} 

FEND 

— >♦ 
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{aO  bO} 

s'  I 


n5 


BEND  x ' 


I 


<>\ 


nl 


{cl} 


{cl}  n‘nFEND 
*}+ 


! { } 


BEND 
+ — 


{cO} 


\ ! 

.i 

n2 


{dl } 


FEND 

•>+ 


Figure  15.  Updated  Graph 


We  observe  that  BEX(n5)  = {{aO  bO}}  does  not  cover  BEX(n3)  = {{aO}}. 
It  is  therefore  necesssary  to  create  a new  node  n6  where  FEX(n6)  = 
FEX(n5)  = {{cl}  {el}}  and  BEX(n6)  s sum({(aO  bO}},  {{aO}})  = {{aO}}. 
The  resulting  structure  is  shown  in  Figure  16.  We  note,  however, 
that  the  arc  leading  from  BEND  to  n6  does  not  satisfy  Property  3 
since  {aO  bO}  is  not  a member  of  {{aO}}.  This  arc,  and  also  the  arc 
leading  from  n6  to  n4,  are  therefore  deleted. 


BEND  {aO  bO}  n5 
>♦- 


{cl} 


FEND 


{aO  bO} 


' n n6 


{} 


BEND  {eO}  I {dl}  FEND 


n2 


Figure  16.  Newly  Updated  Graph 
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It  turns  out  that  there  are  two  additional  updates  to  be  made. 

A new  node  n7,  where  PEX(n7)  « { {dl } > and  BEX(n7)  = UcO}  { eO } } , la 
created  in  the  process.  The  final  graph  is  shown  in  Figure  17.  In 
this  graph  the  FEX  of  each  node  is  equal  to  the  fex  of  each  path 
leading  from  BEND  to  that  node,  and  the  BEX  of  each  node  is  equal  to 
the  bex  of  each  path  leading  from  that  node  to  FEND.  We  have  thus 
produced  the  prime-constraint  graph  for  our  system. 


BEND  {aO  bO)  n5  {cl}  FEND 

J. Sx 'Vi 


ACCOMPLISHMENTS 

In  this  report  we  have  described  a new  technique  for  security 
validation  based  on  the  concept  of  a prime  constraint.  We  have  also 
documented  a computer  program  that  automates  an  important  part  of 
the  analysis:  the  generation  of  a system's  prime-constraint  graph. 

We  have  seen  that  the  set  of  prime  constraints,  as  represented  by 
the  prime-constraint  graph,  allows  us  to  determine  what  deductions 
are  possible  in  a system.  Validation  of  security  is  then  just  a 
matter  of  determining  which  of  the  deductions,  if  any,  constitute  a 
compromise . 

There  are  various  criteria  for  making  that  determination.  In 
the  case  of  multi-level  security,  the  most  straightforward  approach 
is  to  assign  a security  level  to  each  of  the  'visible'  variables, 
and  then  check  for  a prime  constraint  that  shows  a variable  at  one 
security  level  being  compromised  by  other  variables  at  lower 
security  levels.  The  important  thing  to  note  here  is  that  a 
'deduction'  is  now  the  means  for  determining  compromise  rather  than 
the  existence  of  an  'information  flow'. 


COMPLEXITY 

The  most  pressing  problem  that  needs  to  be  addressed  is 
complexity.  We  know  that  while  the  prime-constraint  graph  grows 
quite  modestly  for  some  systems, 9 such  as  shift  registers  and  many 
control  structures,  it  grows  exponentially  for  other  systems,  such 
as  adders  and  multipliers.  It  appears  that  this  exponential  growth 
is  most  likely  to  occur  in  those  systems  corresponding  to  Boolean 
functions  for  which  the  number  of  prime  implicants  grows 
exponentially  (i.e.,  adders  and  multipliers).  There  is  also  a large 
class  of  systems  for  which  we  simply  do  not  know  how  sericus  the 
complexity  problem  is.  For  example,  we  have  no  idea  how  complex  the 
prime-constraint  graph  of  a typical  operating  system  would  be. 


9 The  growth  of  the  prime-oonstralnt  graph  is  measured  relative  to 
the  number  of  two-plaoe  prime  constraints. 
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There  are  a number  of  ways  of  dealing  with  complexity.  One  can 
simply  choose  to  model  a system  in  less  detail,  or  one  can  try  to 
configure  a system  so  that  the  essential  aspects  of  behavior  become 
tractable.  (Partitioning  a system  into  separate  'control'  and  'data 
flow'  components  is  one  approach.)  None  of  these  techniques, 
however,  really  solves  the  problem  of  complexity  since  there  will  be 
everyday  systems  that  remain  completely  Intractable.  The  only  real 
solution,  if  there  is  one,  will  have  to  come  from  further  research 
and  a deeper  understanding  of  the  theory  of  constraints. 


HIERARCHICAL  VALIDATION 

Another  problem,  which  is  related  to  the  complexity  of  the 
prime-constraint  graph,  is  the  computational  load  placed  on  the 
program  for  generating  that  graph.  In  some  cases,  it  is  possible 
for  the  execution  time  of  the  program  to  be  enormously  long  even 
though  the  final  prime-constraint  graph  is  of  modest  size. 

In  a hierarchically-structured  system  it  is  possible  to  get 
around  this  problem  through  a 'hierarchical  validation'.  One  begins 
by  generating  the  'external  prime-constraint  graph'  for  each  of  the 
lowest-level  modules.  This  graph  is  obtained  from  the  complete 
prime-constraint  graph  by  eliminating  all  arcs  having  conditions 
belonging  to  'hidden'  variables.  These  graphs  are  then  'merged'  by 
applying  the  Generate  and  Update  phases  described  in  Section  4 to 
the  composite  graph.  The  process  is  repeated  for  each  successive 
level.  The  final  result  is  the  external  prime-constraint  graph  for 
the  top-most  module(s).  This  final  graph  represents  those  prime 
constraints  that  involve  only  externally-visible  variables.  These 
prime  constraints  are  the  only  ones  we  really  need  be  concerned  with 
in  order  to  perform  a security  validation.  What  makes  this  approach 
attractive,  in  contrast  to  the  prevailing  methodology  for  security 
validation,  is  that  the  same  concepts  and  the  same  techniques  are 
applicable  across  all  levels. 


SUPPORTING  TOOLS 

In  order  to  make  the  tool  described  in  this  report  more  readily 
accessible,  we  have  to  develop  programs  for  both  preprocessing  and 
postprocessing.  Preprocessing  is  needed  to  convert  a system 
description  in  an  applieations-orlented  language,  such  as  a 
program-specification  language  or  a hardware-description  language, 
into  the  language  of  constraints.  Postprocessing  Is  needed  to 
analyze  the  prime-constraint  graph  for  various  properties.  For 
security  validation,  this  analysis  entails  oheoking  for  compromise. 
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Once  the  preprocessing  and  postprocessing  programs  are 
implemented,  we  will  then  have  a completely  automated  tool  for 
security  validation. 
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MODULE  DESCRIPTIONS 


In  each  module  description,  an  interpretation  is  provided  for 
each  argument.  The  LISP  structure  corresponding  to  each 
interpretation  is  as  follows: 

set  - list 

condition  - atomic  symbol  (with  ’variable’  property) 
variable  - atomic  symbol  (with  ’resolved*  and  ’unresolved’  properties) 
term  - set  of  conditions 

node  - atomic  symbol  (with  ’fex’,  ’bex’,  ’fore’,  and  ’back’  properties) 
arc  - atomic  symbol  (with  ’fore’  and  ’back’  properties) 
pnode  - atomic  symbol  (with  ’fex’,  ’bex’,  ’fore’  or  ’back’,  and 

’flag’  properties) 

The  following  descriptions  assume  that  the  reader  is  familiar  with 
the  programming  language  LISP  and  with  the  algorithm  described  in 
Section  4. 


union2  2 arguments:  each  argument:  a set 

(union2  X Y)  returns  the  union  of  X and  Y. 

union 1 1 argument  argument:  a set  of  sets 

(unionl  Q)  returns  the  union  of  the  sets  in  Q. 

Intersect2  2 arguments  each  argument:  a set 

(intersect  X Y)  returns  the  intersection  of  X and  Y. 

intersect 1 1 argument  argument:  a set  of  sets 

(lntersectl  Q)  returns  the  intersection  of  the  sets  in  Q. 
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subtract  2 arguments  each  argument:  a set 

(subtract  X Y)  returns  X - Y. 


includes  2 arguments  each  argument:  a set 

(includes  X Y)  returns  t if  X contains  Y,  and  nil  otherwise. 


same  2 arguments  each  argument:  a set 

(same  X Y)  returns  t if  X and  Y represent  the  same  set,  and  nil 
otherwise. 


like  2 arguments  each  argument:  a set  of  sets 

Identical  to  'same'  except  that  each  argument  is  treated  as  a 
set  of  sets. 


pairs  2 arguments  each  argument:  a set 

(pairs  X Y)  returns  the  Cartesian  product  of  X and  Y. 


varsyms  1 argument  argument:  a term 

(varsyms  trm)  returns  a list  of  those  variables  with  conditions 
in  trm. 


inout  2 arguments  1st  argument:  a variable 

2nd  argument:  a term 

(inout  var  trm)  returns  a dotted-pair,  the  car  of  which  is  a 
the  set  of  conditions  in  trm  belonging  to  var,  and  the  odr  of 
which  is  the  set  of  conditions  in  trm  not  belonging  to  var. 
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covers  2 arguments  each  argument:  a term 

(covers  trml  trm2)  returns  t if  trml  covers  trm2,  and  nil 
otherwise . 


embraces  2 arguments  1st  argument:  a set  of  terms 

2nd  argument:  a term 

(embraces  Q trm)  returns  t if  one  of  the  terms  in  Q covers  trm, 
and  nil  otherwise. 


contains  2 arguments  each  argument:  a set  of  terms 

(contains  X Y)  returns  t if  X covers  Y,  and  nil  otherwise.  It 
is  assumed  that  X is  the  set  of  all  prime  implicants  for  the 
set  of  states  covered  by  X. 


gib  2 arguments  each  argument:  a term 

(gib  trml  trm2)  returns  the  greatest  lower  bound  of  trml  and 
trm2.  If  there  is  no  gib,  then  fno'  is  returned. 


resolve  3 arguments  1st  argument:  a variable 

2nd  & 3rd  arguments:  terms 

(resolve  var  trml  trm2)  returns  the  resolvent  of  trml  and  trm2 
using  var  as  the  resolving  variable. 


resolvents  2 arguments  1st  argument:  a term 

2nd  argument:  a set  of  terms 

(resolvents  trm  Q)  returns  a dotted-pair.  Its  car  is  the  set 
of  all  resolvents  between  trm  and  each  of  the  terms  in  Q.  Its 
cdr  is  the  set  of  all  terms  in  Q not  oovered  by  trm. 


I 

1 

I 


- — L 


primes 


2 arguments 


each  argument:  a set  of  terms 


(primes  X Y)  returns  the  set  of  prime  implioants  for  the  union 
of  states(X)  and  states(Y). 


sum 


2 arguments 


each  argument:  a set  of  terms 


Identical  to  'primes'  except  that  'sum'  assumes  that  the  terms 
in  each  argument  are  relatively  prime. 


product 


2 arguments 


each  argument:  a set  of  terms 


(product  X Y)  returns  the  set  of  prime  implicants  for  the 
intersection  of  states(X)  and  states(Y). 


setvariable 


1 argument 


argument:  a set  of  conditions 


(setvariable  v)  creates  a variable  whose  value  is  v.  The 
variable  is  given  two  properties,  'resolved'  and  'unresolved', 
which  are  set  to  nil.  The  new  variable  is  returned. 


getnode 


4 arguments  1st  & 3rd  arguments:  'fex*  & 'bex' 

or 

'bex'  & 'fex' 
2nd  & 4th  arguments:  sets  of  terms 


(getnode  exl  xl  ex2  x2)  causes  a search  for  an  existing  node 
whose  exl  property  is  xl,  and  whose  ex2  property  is  x2.  If  no 
such  node  is  found,  then  one  is  created.  The  name  of  the 
existing  or  newly-created  node  is  returned. 
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getarc  5 arguments  1st  argument:  a term 

2nd  & 4th  arguments:  'fore*  & 'back' 

or 

•back'  4 'fore' 
3rd  & 5th  arguments:  nodes 

(getarc  trm  dirl  dl  dir2  d2)  causes  a search  for  an  existing 
arc  whose  value  is  trm,  whose  dirl  is  dl,  and  whose  dir2  is  d2. 
If  no  such  arc  is  found,  then  one  is  created.  The  name  of  the 
existing  or  newly-created  arc  is  returned. 


init 


1 argument 


argument:  a two- term  list 


Interprets  its  argument  as  a two-place  constraint,  and  creates 
a two-arc  path  from  BEND  to  FEND. 


initialize  2 arguments  1st  argument:  a set  of  sets 

of  conditions 

2nd  argument:  a set  of  two-term 
lists 

Performs  a 'setvariable'  for  each  set  of  conditions  in  the 
first  argument.  Creates  the  BEND  and  FEND  nodes.  Performs  an 
'init'  for  each  of  the  two-term  lists  in  the  second  argument. 


check 


2 arguments  1st  argument:  a term 

2nd  argument:  a set  of  terms 


(check  trm  Q)  returns  t if  trm  is  not  properly  covered  by  any 
of  the  terms  in  Q,  and  nil  otherwise. 


pairnodes  5 arguments  1st  & 2nd  arguments:  nodes 

3rd,  4th,  4 5th  arguments: 

*bex' , 'fex',  4 'BEND' 
or 

•fax',  'bex\  4 'FEND' 

(pairnodes  a n exl  ex2  end)  computes  the  'transform'  of  m and 
n.  The  two  oho ices  for  exl,  ex2,  and  end  determine  whether  the 
two  nodes  are  assumed  to  precede  or  follow  the  arcs  being 


resolved  by  nresolve.  If  either  m or  n is  end,  then  the  other 
node  is  returned.  Otherwise,  the  fex  and  bex  of  a potential 
new  node  are  computed.  The  exl  property  of  this  potential  node 
is  set  to  the  sum  of  m's  and  n's  exl  properties,  and  the  ex2 
property  is  set  to  the  product  of  m's  and  n's  ex2  property.  If 
the  ex2  property  of  this  potential  node  is  nil,  then  'bad'  is 
returned.  Otherwise,  an  atomic  symbol,  called  a 'pnode',  is 
created  from  exl,  m,  and  n.  If  this  pnode  did  not  previously 
exist,  or  if  it  had  existed  but  had  not  been  'merged',  then  the 
pnode  is  returned  as  the  value  of  pairnodes.  If,  however,  the 
pnode  had  existed  and  had  been  merged,  then  the  value  of  the 
pnode  will  be  the  transform  of  m and  n,  and  it  is  this  node 
that  is  returned  by  pairnodes. 


complete  6 arguments  1st  argument:  a pnode 

2nd  argument:  a two-arc  set 
3rd-6th  arguments: 

'bex',  'fex',  'back',  & 'BEND' 
or 

•fex',  'bex',  'fore',  & 'FEND' 

(complete  y p exl  ex2  dir  end)  attempts  to  complete  the  pair  of 
paths  that  led  to  y being  created.  The  two  arcs  in  p are  the 
candidates  for  the  next  step  in  this  completion.  First,  the 
gib  of  the  terms  associated  with  these  two  arcs  is  computed. 

If  it  does  not  exist,  then  complete  indicates  that  no 
completions  are  possible  by  returning  without  taking  any 
further  action.  Otherwise,  pairnodes  is  called  for  the  two  dir 
nodes  associated  with  the  two  arcs  in  p.  If  'bad'  is  returned, 
then  complete  terminates  immediately  indicating  that  no 
completions  are  possible.  Otherwise,  two  tests  are  made  to 
insure  that  the  two  arcs  are  suitable  for  being  merged.  If 
either  test  fails,  then  complete  again  returns  immediately.  If 
all  hurdles  are  overcome,  then  the  symbol  returned  by  pairnodes 
is  checked.  If  it  is  a node  or  a 'merged'  pnode,  then  a 
pointer  to  this  node  or  pnode  is  added  to  y in  anticipation  of 
a possible  merge,  and  control  is  returned.  If,  however,  the 
symbol  returned  by  pairnodes  is  an  'unmerged'  pnode,  then 
complete  ia  called  for  that  symbol  and  each  pair  of  next- 
possible  arcs.  If  at  the  end  of  these  calls  the  pnode  has 
accumulated  at  least  one  pointer,  then  a pointer  to  this  pnode 
is  added  to  y.  The  program  then  terminates. 
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merge 


3 arguments  1st  argument:  a pnode 

2nd  & 3rd  arguments:  'back' 


or 

& 'back' 


(merge  z dirl  dir2)  first  causes  a node  to  be  created  for  the 
fex  and  bex  supplied  by  z.  The  value  of  z Is  set  to  this  node. 
Then  each  pointer  of  z is  checked  to  see  if  it  points  to  a 
node,  a 'merged'  pnode,  or  an  'unmerged'  pnode.  The  'unmerged' 
pnode  is  merged  immediately.  The  appropriate  arc  is  then  added 
between  the  node  associated  with  the  pointer  and  the  node 
associated  with  z.  The  program  then  returns. 


ncovered 


6 arguments  1st  argument:  an  arc 

2nd  argument:  a set  of  arcs 
3rd-5th  arguments:  'back'  A '! 


(ncovered  a 0 dirl  dir2  ex  done)  returns  t if  a prefix  of  every 
path  beginning  with  Arc  a and  proceeding  in  the  dirl  direction 
is  covered  by  a path  beginning  with  an  arc  in  Q,  also 
proceeding  in  the  dirl  direction,  and  terminating  at  either 
BEND  or  FEND,  nil  is  returned  otherwise. 


re  3 arguments  1st  argument:  an  arc 

2nd  & 3rd  arguments:  'back'  & 'fore' 

or 

'fore'  & 'back' 

(remove  a dirl  dir2)  removes  Arc  a and  all  those  nodes  and  arcs 
in  the  dirl  direction  that  are  no  longer  part  of  a path  from 
BEND  to  FEND. 


prune  3 arguments  1st-3rd  arguments: 

'back',  'fore',  & 'fex' 
or 

’fore',  'back',  A 'bex' 

Prunes  from  the  current  graph  those  newly-created  arcs  and 
those  arcs  having  a node  in  oommon  with  a newly-created  arc 
that  are  superfluous.  Note:  prune  is  included  only  for  the 
sake  of  efficiency  and  is  not  essential  to  the  algorithm. 


nresolve  3 arguments  1st  argument:  a variable 

2nd  & 3rd  arguments:  area 

(nreaolve  var  al  a2)  attempts  a resolution  centered  around  Arcs 
al  and  a2  with  var  as  the  resolving  variable.  Complete  finds 
the  necessary  pairs  of  paths  and  merge  performs  the  actual 
'merging'  of  these  paths. 


I 


generate  1 argument  argument:  a variable 

(generate  v)  causes  (nreaolve  v al  a2)  to  be  performed  for  each 
pair  of  arcs  al  and  a2  that  have  not  been  previously  nresolved 
and  that  have  terms  with  at  least  one  condition  belonging  to  v. 


split  7 arguments  1st  & 2nd  arguments:  nodes 

3rd-7th  arguments: 

'bex',  'fex',  'back',  'fore',  & 'FEND' 
or 

'fex',  'bex',  'fore',  'back',  A 'BEND' 

(split  m n exl  ex2  dirl  dir2  end)  looks  for  a pair  of  nodes 
nextm  and  nextn  for  which  there  are  two  arcs  a and  b such  that: 
m is  the  dir2  of  a,  n is  the  dir2  of  b,  nextm  is  the  dirl  of  a, 
nextn  is  the  dirl  of  b,  and  the  term  for  a covers  the  term  for 
b.  The  ex2  of  nextm  is  then  used  to  'update'  the  ex2  of  nextn. 


update  5 arguments  1st-5th  arguments: 

'bex',  'fex',  'back',  'fore',  A 'FEND' 
or 

'fex',  'bex',  'fore',  'back',  A 'BEND' 

Updates  the  fex's  and  bex's  of  the  nodes  produced  by  the 
generate  phase. 


pcgraph 


2 arguments  1st  argument:  a set  of  sets 

of  conditions 

2nd  argument:  a set  of  two-term 
lists 


(pcgraph  V C)  generates  the  prime  constraint  graph  for  the  set 
of  variables  V and  the  set  of  two-place  constraints  C.  Initial 
function  called  by  the  user. 


expand 


1 argument  argument:  'ARCS' 


Expands  the  set  of  arcs.  Final  function  called  by  the  user. 


mmmt 
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PCGRAPH  LISTING 
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1 ;; 


(ERRATUM:  The  use  of  *fex'  and  'bex'  in  this  listing  is  reversed 
from  that  in  the  text.  A 'fex'  in  the  listing  corresponds  to  a 
'bex'  in  the  text,  and  vice  versa.) 
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(defur  resolve  (var  tral  tr«2) 

(prog  (xl  i2  rl  rt  r g) 

(setq  xl  (Inout  var  tral)) 
(setq  rl  (oar  xl)) 


(cond  ((covers  (eval  (car  A))  tr«)  (return  (car  A)))))))) 


(cond  ((null  (eval  z))  (return  z)) 
(t  (return  (eval  z)))))) 


(defun  ncovered  (a  Q dirl  dir2  ex  done) 
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(defun  prune  (dlrl  dir2  ex) 

(do  ((X  HEW ARCS  (cdr  X))  (n>  (N) ) 

( (null  X)  (do  ((I  N (cdr  Y))  (A)) 
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(defun  generate  (v) 

(cood  ((null  (get  v 'unresolved))  nil) 

(t  (do  () 

((null  (get  v 'unresolved))  t) 


